<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="Laurent Deniau">
   <meta name="GENERATOR" content="Mozilla/4.76 [en] (X11; U; Linux 2.2.17 i686) [Netscape]">
   <title>Object Oriented Programming in C</title>
</head>
<body text="#000000" bgcolor="#C8C8C8" link="#0000EF" vlink="#51188E" alink="#FF0000">
&nbsp;
<table CELLPADDING=10 COLS=1 WIDTH="100%" BGCOLOR="#FFC6AC" NOSAVE >
<tr NOSAVE>
<td NOSAVE>
<center><b><font face="Arial,Helvetica"><font size=+3>Object Oriented Programming
in C</font></font></b></center>
</td>
</tr>
</table>

<center>
<p><b><font size=+1><a href="mailto:Laurent.Deniau@cern.ch">Laurent Deniau</a></font></b>
<p>March 10, 2001
<br>revised May 17, 2001
<p>[ <a href="#Introduction">Introduction</a> | <a href="#Object_Model">Object
Model</a>
<br><a href="#Object">Object</a> | <a href="#Class">Class</a> |
<a href="#Messages">Messages</a>
| <a href="#Methods">Methods</a> | <a href="#Encapsulation">Encapsulation</a>
| <a href="#Interface">Interface</a> | <a href="#Implementation">Implementation</a>
<br>&nbsp;<a href="#Inheritance">Inheritance</a> | <a href="#Multiple_Inheritance">Multiple
Inheritance</a> | <a href="#Polymorphism">Polymorphism</a> | <a href="#Abstract_Class">Abstract
Class</a> | <a href="#Genericity">Genericity</a> | <a href="#Exceptions">Exceptions</a>
<br><a href="#Debugging">Debugging</a> | <a href="#ISO_C99">ISO C99</a>
| <a href="#Performances">Performances</a> | <a href="#Keywords">Keywords</a>
| <a href="#Examples">Examples</a> |
<a href="#References">References</a>
| <a href="#Mailing_List">Mailing List</a> | <a href="#ChangeLog">ChangeLog</a>
]</center>

<p><br>
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Introduction"></a><b><font face="Arial,Helvetica"><font size=+2>Introduction</font></font></b></td>
</tr>
</table>

<p>This paper presents some programming techniques that allow large projects
based on ISO C89 to get the benefits of object oriented design. It doesn't
intend to be a course on OOP techniques and assumes the reader to have
a good knowledge of the C language. Since OOPC is based on the <i>C++ Object
Model</i>, a good knowledge of C++ may help to understanding it better.
These techniques may be useful for programmers who have not a C++ compiler
for their architecture (calculators, small systems, embedded systems).
It may also be useful for people who are disappointed by C++ compilers
which do not behave like the norm says or even do not support all the C++
features or by C++ APIs that change from time to time. In fact, I don't
know (at the revised date of this paper) any compiler which fully support
the norm C++98. It is clear that the techniques presented here have not
the pretension to replace C++, that is impossible without a <i>cfront</i>
translator (OOPC uses only C macros and few C lines), but it provides enough
to do serious OOP:
<ul>
<li>
The <i>procedural model</i> using C functions...</li>

<li>
The <i>abstract data type model</i> using public interface and private
implementation as well as data and names encapsulation.</li>

<li>
The <i>object-oriented model</i> using (multiple) inheritance and polymorphism
which allows to manipulate different object types through a common interface.</li>
</ul>
OOPC also provides mechanisms to handle easily:
<ul>
<li>
Genericity (C++: templates).</li>

<li>
Exceptions (C++: exceptions, <tt>try</tt>, <tt>catch</tt>, <tt>throw</tt>,
<tt>auto_ptr</tt>).</li>

<li>
Debugging (dynamic allocation, function call, object construction).</li>
</ul>
Comparing to the <i>C++ Object Model</i>, OOPC does not provide:
<ul>
<li>
Automatic object construction and destruction (must be explicitly called).</li>

<li>
Automatic array of objects construction and destruction (must be done by
user).</li>

<li>
Non-polymorphic objects (all objects are polymorphic).</li>

<li>
Virtual inheritance (too complex and not essential).</li>

<li>
Pointer to virtual member function handling polymorphism (too complex or
slow).</li>

<li>
And more...</li>
</ul>
Beside the advantages of the OOPC, one important constraint is to keep
<b>type
checking everywhere</b> to ensure code quality and good debugging and therefore
it forbids the extensive use of untyped pointers (<tt>void*</tt>) for polymorphism
purposes. Another constraint is to provide a mechanism for name encapsulation
to allow same method to be applied to different objects while C89 does
not support function overloading. Finally we must provide a mechanism to
allow preprocessor macros to accept a variable number of arguments like
the C99
<tt>__VA_ARGS__</tt> predefined macro does. In the following, we
will use some terminology borrowed&nbsp; from C++ (and Objective C) but
with a slight difference about the meaning of <i>object</i> (C++: class
object) and <i>class</i> (C++: class). To avoid any confusion, this paper
will use the following therminology:
<ul>
<li>
A <i>method</i> is a member function (C++: member function).</li>

<li>
An <i>object method</i> (message) is a polymorphic member function (C++:
virtual member function = method).</li>

<li>
A <i>class method</i> is a member function not working on an object (C++:
static member function).</li>

<li>
An <i>object</i> includes all the non-static data plus a hidden pointer
(C++: class object with methods).</li>

<li>
A<i> virtual table</i> includes all the object methods (C++: virtual table).</li>

<li>
A <i>class</i> includes all the static data, methods and class methods
(C++: class).</li>
</ul>
To use the proposed OOPC techniques, you need to include the header files
<tt><a href="ooc.h">ooc.h</a></tt>
(depends on <tt><a href="exception.h">exception.h</a></tt> and <tt><a href="ooexception.h">ooexception.h</a></tt>)
in your project and to link it with the <tt><a href="ooc.c">ooc.c</a></tt>
and <tt><a href="exception.c">exception.c</a></tt> files. If you want to
debug your OOPC program, you need to include the header file <tt><a href="oodebug.h">oodebug.h</a></tt>
and to link your project with <tt><a href="oodebug.c">oodebug.c</a></tt>.
To be informed about the OOPC evolution and discussion you can subscribe
to the <a href="mailto:forum-oopc@listbox.cern.ch">forum-oopc</a> mailing
list (see <a href="#Mailing_List">Mailing List</a>).
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Object_Model"></a><b><font face="Arial,Helvetica"><font size=+2>Object
Model</font></font></b></td>
</tr>
</table>

<p>OOPC is based on the <i>Object-Oriented Model</i> described in this
section and strongly inspired from the <i>C++ Object Model</i>. If you
are not familliar or simply not interested by object model, you can skip
this section although reading it may greatly help for the understanding
of the behaviour of OOPC and even of C++.
<p>This model is built around three different types available for each
class plus a general RTTI (Run-Time Type Information) type:
<ul>
<li>
The <i>object</i> collects the class non-static data (any instances).</li>

<li>
The <i>class</i> collects the class static data, class methods and methods
(one instance, doesn't exist in C++).</li>

<li>
The <i>virtual table</i> collects the class object methods (one instance).</li>

<li>
The <i>type info</i> collects the class RTTI (one intance).</li>
</ul>

<center><table BORDER WIDTH="100%" NOSAVE >
<caption><b>Object Model Representation</b></caption>

<tr NOSAVE>
<td ALIGN=LEFT VALIGN=TOP NOWRAP BGCOLOR="#99FFCC" NOSAVE><tt>object&nbsp;&nbsp;&nbsp;&nbsp;
(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vtbl&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type_info&nbsp; (1)</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------+</tt>
<br><tt>|&nbsp;&nbsp; __vptr | ---+-> |&nbsp;&nbsp; __info | -----> |&nbsp;&nbsp;
__name |</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; | __offset |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; __class |</tt>
<br><tt>|[data]&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; __super |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |[methods] |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
__extra |</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | __offset |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------+</tt>
<br><tt>class&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1)&nbsp; |</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp; __vptr | ---+</tt>
<br><tt>|&nbsp;&nbsp; ctor() |</tt>
<br><tt>|&nbsp;&nbsp; dtor() |</tt>
<br><tt>|&nbsp;&nbsp; ator() |</tt>
<br><tt>+----------+</tt>
<br><tt>|[methods] |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>+----------+</tt></td>
</tr>
</table></center>

<p>The methods in the previous representation can be classified as follow:
<ul>
<li>
Methods in the <tt>vtbl</tt> are <i>object methods</i> (C++: virtual member
functions).</li>

<li>
Methods in the <tt>class</tt> working on an object are <i>methods</i> (C++:
member functions).</li>

<li>
Methods in the <tt>class</tt> not working on an object are <i>class methods</i>
(C++: static member functions).</li>
</ul>
The <tt>ctor()</tt> has always the same name as the class and therefore
it is always called by <tt><i>class</i>.<i>class</i>()</tt> (C++: default
constructor <tt><i>class</i>::<i>class</i>()</tt>). The <tt>dtor()</tt>
has always the same name as the class name preceded by an underscore (C++:
tilde) and therefore is always called by <tt><i>class</i>._<i>class</i>()</tt>
(C++: default destructor <tt><i>class</i>::~<i>class</i>()</tt>). The <tt>ator()</tt>
is always called <tt>alloc()</tt> (C++: default allocator <tt>new(<i>class</i>)</tt>)
and may throw <tt>ooc_bad_alloc</tt> exception upon failure. In OOPC, the
default constructor&nbsp; and allocator are defined, declared and generated
since they return only a well formed instance of the object without any
dynamic initialization (only static initializations can be performed),
but the default destructor is only defined and declared (not generated)
since it may require some dymanic freeing and therefore needs to be provided
by the class designer (even if empty).
<p>The <tt>__vptr</tt> in <tt>object</tt> points to the virtual table and
allows to call object methods without knowing its type. This is the key
point of the polymorphism mechanism. It also allows to reach the class
RTTI data required for dynamic casting.
<p>The <tt>__vptr</tt> in <tt>class</tt> also points to the virtual table
and allows to bypass the polymorphism mechanism. It also allows classes
to behave like objects (with some limitations) for object methods calls
and RTTI purposes.
<p><b>Object Model and Single Inheritance</b>
<p>The principle used for single inheritance is the structure mapping,
that means if <tt>object2</tt> inherits from <tt>object1</tt>, the data
of object1 are at the beginning of <tt>object2</tt>, and therefore an <tt>object2</tt>
can directly be used everywhere an <tt>object1</tt> is expected. But to
guarantee the invariance of data alignment through inheritance, object
data members must be encapsulated into a structure. Obviously, the presence
of the constant <tt>__vptr</tt> pointer, which may point to different <tt>vtbl</tt>,
inside the structure forbids bitwise-copy of objects which must be performed
member by member. The same technique is used to build virtual table of
<tt>object2</tt>
but the encapsulation is not required since all slots have the same size
(i.e. function pointers). RTTI structures are simply chained. Here follows
the equivalent model representation:
<br>&nbsp;
<center><table BORDER WIDTH="100%" NOSAVE >
<caption><b>Object Model: Single inheritance</b></caption>

<tr NOSAVE>
<td ALIGN=LEFT VALIGN=TOP NOWRAP BGCOLOR="#99FFCC" NOSAVE><tt>object2&nbsp;&nbsp;&nbsp;
(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vtbl2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
type_info2 (1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type_info1 (1)</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------+</tt>
<br><tt>|&nbsp;&nbsp; __vptr | ---+-> |&nbsp;&nbsp; __info | -----> |&nbsp;&nbsp;
__name |&nbsp;&nbsp;&nbsp; +-> |&nbsp;&nbsp; __name |</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; | __offset |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; __class | ---+&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...
|</tt>
<br><tt>|[data1]&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; __super |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |[methods1]|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
__extra |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | __offset |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|[data2]&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |[methods2]|</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; +----------+</tt>
<br><tt>class2&nbsp;&nbsp;&nbsp;&nbsp; (1)&nbsp; |</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp; __vptr | ---+</tt>
<br><tt>|&nbsp;&nbsp; ctor() |</tt>
<br><tt>|&nbsp;&nbsp; dtor() |</tt>
<br><tt>|&nbsp;&nbsp; ator() |</tt>
<br><tt>+----------+</tt>
<br><tt>|[methods] |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>+----------+</tt></td>
</tr>
</table></center>

<p><b>Object Model and Multiple Inheritance</b>
<p>The principle used for multiple inheritance is the aggregation of objects,
that means if <tt>object3</tt> inherits from <tt>object2</tt> and <tt>object1</tt>,
the data of <tt>object1</tt> are at the begining of <tt>object3</tt>, followed
by the data of <tt>object2</tt> including its <tt>__vptr</tt> pointer.
Therefore an <tt>object3</tt> can directly be used everywhere an <tt>object1</tt>
is expected, like for single inheritance, but it can also be used everywhere
an <tt>object2</tt> is expected after a small offset adjustment to the
<tt>object2</tt>
address inside the <tt>object3</tt>. Since <tt>object2</tt> is defined
as an encapsulated member of <tt>object3</tt>, it is very easy to know
its offset and <tt>&amp;object3->object2</tt> tells to the compiler to
do this offset ajustment. Here follows the equivalent model representation:
<br>&nbsp;
<center><table BORDER WIDTH="100%" NOSAVE >
<caption><b>Object Model: Multiple inheritance</b></caption>

<tr ALIGN=LEFT VALIGN=TOP NOSAVE>
<td ALIGN=LEFT VALIGN=TOP NOWRAP BGCOLOR="#99FFCC" NOSAVE><tt>object3&nbsp;&nbsp;&nbsp;
(*)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vtbl3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
type_info3 (1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type_info1 (1)</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------+</tt>
<br><tt>|&nbsp;&nbsp; __vptr | ---+-> |&nbsp;&nbsp; __info | -----> |&nbsp;&nbsp;
__name |&nbsp;&nbsp;&nbsp; +-> |&nbsp;&nbsp; __name |</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; | __offset |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; __class | ---+&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...
|</tt>
<br><tt>|[data1]&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; __super |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |[methods1]|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;
__extra |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | __offset |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp; __vptr2 | -+ |&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------+</tt>
<br><tt>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ---+&nbsp; +---> |&nbsp;
__info2 | --+</tt>
<br><tt>|[data2]&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |__offset2
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; type_info2 (1)</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ---+&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
+----------+</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |[methods2]|&nbsp;&nbsp;
+--> |&nbsp;&nbsp; __name |</tt>
<br><tt>|[data3]&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
... |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |[methods3]|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; +----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------+</tt>
<br><tt>class3&nbsp;&nbsp;&nbsp;&nbsp; (1)&nbsp; |</tt>
<br><tt>+----------+&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp; __vptr | ---+</tt>
<br><tt>|&nbsp;&nbsp; ctor() |</tt>
<br><tt>|&nbsp;&nbsp; dtor() |</tt>
<br><tt>|&nbsp;&nbsp; ator() |</tt>
<br><tt>+----------+</tt>
<br><tt>|[methods] |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>+----------+</tt></td>
</tr>
</table></center>

<p>The RTTI of <tt>object3</tt> and <tt>object1</tt> are chained, but the
RTTI of <tt>object2</tt> remains separate since <tt>object2</tt> inside
<tt>object3</tt>
must behave exactly as a true <tt>object2</tt>. In fact, the only difference
between a true <tt>object2</tt> and the <tt>object2</tt> inside <tt>object3</tt>
is the value of the field <tt>__offset2</tt> in the virtual table which
holds the offset of <tt>object2</tt> inside <tt>object3</tt>. A true <tt>object2__vptr</tt>
would point to the virtual table of <tt>object2</tt> and not inside the
virtual table of <tt>object3</tt> and therefore the
<tt>__offset</tt> field
value would be zero.
<p>&nbsp;For more information about the <i>OOPC Object Model</i>, see the
pseudo C file <tt><a href="objectModel.c">objectModel.c</a></tt>.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Object"></a><b><font face="Arial,Helvetica"><font size=+2>Object</font></font></b></td>
</tr>
</table>

<p>Assuming that a person may be identified by its name, this information
should be encapsulated into an <i>object</i> to reflect the ownership of
these data by the person. A typical approach would be:
<blockquote><tt>struct t_person {</tt>
<br><tt>&nbsp; char *name;</tt>
<br><tt>};</tt></blockquote>
In fact, objects and classes in OOPC are always defined as aggregations
(structures or unions). It answers to the second constraint: the name encapsulation.
OOPC macros achieve simply the object definition which in reality looks
like:
<blockquote><tt>typedef union {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt>
<br><tt>&nbsp; struct _ooc_vtbl_person const*const <b>__vptr</b>; /* generated
*/</tt>
<br><tt>&nbsp; struct _ooc_vtbl_object const*const <b>__iptr</b>; /* generated
*/</tt>
<br><tt>&nbsp; struct {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt>
<br><tt>&nbsp;&nbsp;&nbsp; <b>t_object</b> const <b>private</b>(_);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt>
<br><tt>&nbsp;&nbsp;&nbsp; char const* <b>private</b>(name);</tt>
<br><tt>&nbsp; } <b>m</b>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt>
<br><tt>} t_person;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt></blockquote>
From this definition, which is exactly what OOPC does, we can do the following
remarks:
<ul>
<li>
All <i>objects type</i> have a <tt>t_</tt> concatenated in front of its
(class) name to specify that is an object/a type (i.e. <tt>t_person</tt>).</li>

<li>
All <i>objects</i> begin with a hidden member constant pointer <tt>__vptr</tt>
to their <i>virtual table</i> (i.e. hidden type <tt>struct _ooc_vtbl_person</tt>).</li>

<li>
All <i>objects</i> begin with a hidden member constant pointer <tt>__iptr</tt>
to their <i>virtual table information</i> part (i.e. hidden type <tt>struct
_ooc_vtbl_object</tt>).</li>

<li>
All <i>objects</i> always inherit from the base object <tt>t_object</tt>
(i.e. <tt>t_object const private(_)</tt>) or from another object.</li>

<li>
All <i>objects</i> have their data encapsulated into the <tt>m</tt> structure
through which you can access objects members (i.e. <tt>obj->m.name</tt>).</li>

<li>
All <i>objects instances</i> have a size equal to sizeof <tt>m</tt> = sizeof
<tt>__vptr</tt>
+ sizeof data + data alignment.</li>
</ul>
The object designer should never take care about the encapsulation of its
data whose purpose is only to reflect the <i>Object Model</i> structure
and guarantee the data alignment invariance through inheritance, and instead
he should use the OOPC object interface (see <tt><a href="examples/person.h">person.h</a></tt>
for a complete interface):
<blockquote><tt>#define <b>OBJECT</b> person</tt>
<p><b><tt>BASEOBJECT_INTERFACE</tt></b>
<p><tt>&nbsp; char const* <b>private</b>(name);&nbsp; /* object member
*/</tt>
<p><b><tt>BASEOBJECT_METHODS</tt></b>
<p><tt>&nbsp; void <b>constMethod</b>(print);&nbsp;&nbsp;&nbsp; /* object
method */</tt>
<p><b><tt>ENDOF_INTERFACE</tt></b></blockquote>
The <tt>private()</tt> macro transforms the token of the field
<tt>name</tt>
into something which is unreachable outside from the class implementation
(C++: private). The <tt>public()</tt> macro is also available to define
public (reachable) fields (C++: public). In the <tt>BASEOBJECT_METHODS</tt>
section, the object method (message) <tt>print</tt> is defined as a <i>constant
object method</i> (C++: constant virtual member function) using the
<tt>constMethod()</tt>
macro, that means it does not modify the <tt>this</tt> pointer. The <tt>method()</tt>
macro is also available to define non-constant object methods. Note that
the class person does not derive from any other class and therefore is
defined as a <i>base object</i>.
<p>Declaring an object instance, a pointer to an object instance, a constant
pointer to an object instance and a constant pointer to a constant object
instance can be done as in C++:
<ul><tt>t_person obj_auto;</tt>
<br><tt>t_person *obj_ptr;</tt>
<br><tt>t_person *const obj_const_ptr;</tt>
<br><tt>t_person const*const const_obj_const_ptr;</tt></ul>
Of course, the variables need to be properly initialized before being used.
Usually, the third declaration is used since most of the OOPC macros wait
for an object pointer and declaring the pointer as constant protects it
against a misassignment.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Class"></a><b><font face="Arial,Helvetica"><font size=+2>Class</font></font></b></td>
</tr>
</table>

<p>Classes collect and encapsulate the following information:
<ul>
<li>
<i>Static data</i>: data with one instance per class (C++: static member).</li>

<li>
<i>Class methods</i>: non-polymorphic methods without the <tt>this</tt>
pointer (C++: static member function).</li>

<li>
<i>Methods</i>: non-polymorphic methods with the <tt>this</tt> pointer
(C++: member function).</li>

<li>
A hidden member constant pointer <tt>__vptr</tt> to its <i>virtual table</i>.</li>
</ul>
OOPC macros achieve simply the class definition (and declaration) which
in reality looks nearly like:
<blockquote><tt>struct _ooc_class_person {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt>
<br><tt>&nbsp; struct _ooc_vtbl_person const*const <b>__vptr</b>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt>
<br><tt>&nbsp; t_person (*const person)(void);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt>
<br><tt>&nbsp; void (*const _person)(t_person *const <b>this</b>);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* defined&nbsp;&nbsp; */</tt>
<br><tt>&nbsp; t_person *const (*const alloc)(void);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt>
<p><tt>&nbsp; t_person *const (*const new)(char const name[]);</tt>
<br><tt>&nbsp; void (*const init)(t_person *const <b>this</b>, char const
name[]);</tt>
<p><tt>} person;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* generated */</tt></blockquote>
by the equivalent (which must follow the object interface, see <tt><a href="examples/person.h">person.h</a></tt>
for a complete interface):
<blockquote><b><tt>CLASS_INTERFACE</tt></b>
<p><tt>&nbsp; t_person *const <b>classMethod_</b>(new) char const name[]
__;</tt>
<br><tt>&nbsp; void <b>method_</b>(init) char const name[] __;</tt>
<p><b><tt>ENDOF_INTERFACE</tt></b></blockquote>
Here, the declared variable <tt>person</tt> is the class <i>itself</i>
of person while <tt>t_person</tt> has been previously defined to be the
object <i>type</i> of person. The important difference appearing here is
that we need only one class person (instance) while we need a lot of objects
person (instances). The hidden type <tt>struct _ooc_class_person</tt> should
never be used (no necessity).
<p>In the class definition and declaration above, we make the difference
between the <i>class method</i> and the <i>method</i>. The latter requires
a <tt>t_<i>object</i> *const</tt> (i.e. <tt>t_person *const</tt>) as it
first argument and this pointer is referenced as the <tt>this</tt> pointer
inside the method (C++: <tt>this</tt>). If the method is a constant method
(C++: constant member function), the <tt>this</tt> pointer will be of type
<tt>t_<i>object</i>
const*const</tt>. Class methods returning a <tt>t_<i>object</i>*</tt> are
called <i>objects factory</i>.
<p>The special
<tt>_(<i>args</i>) <i>args</i> __</tt> declaration is the
mechanism used to extend the <tt>method</tt> macro to any number of arguments.
Each time a <b>token/keyword finishes with a <tt>_ </tt>it waits for the
closure
<tt>__</tt></b>. This artifact is not required if you have a C99
preprocessor (see <a href="#ISO_C99">ISO C99</a>).
<p>Note: If you don't know where to put your methods, you should remind
that classes should only contain <i>class methods</i> like <tt>new()</tt>
(object factory) and methods strongly related to the object type like <tt>init()</tt>
and <tt>copy()</tt>. All other methods should be considered as object methods.
If you have any doubts, use object methods, this will avoid any big changes
in future interfaces of derived classes. Moving a method from the object
definition to the class definition bring only slights changes (remove polymorphism).
Moving a method from the class definition to the object definition can
be a major task of a project (add polymorphism).
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Messages"></a><b><font face="Arial,Helvetica"><font size=+2>Messages</font></font></b></td>
</tr>
</table>

<p>In order to use <tt>person</tt> objects in our program, we still need
to know how to <i>send messages</i> to an object. In this section we use
the terminology <i>sending messages (to an object)</i> while in the <a href="#Methods">Methods</a>
section, we use the terminology
<i>calling methods (of a class)</i>. We
always send a message to an object by using the two commands
<tt>sendMsg(<i>object</i>,
<i>message</i>)</tt>
and
<tt>sendMsg_(<i>object</i>,
<i>message</i>)
<i>args</i> __</tt>:
<blockquote><tt>t_person *const per = person.new("Brown");</tt>
<br><tt><b>sendMsg</b>(per, print);</tt>
<br><tt><b>delete</b>(per);</tt></blockquote>
The first line creates (allocates and initializes) a new person <tt>per</tt>
with some initialization arguments (<tt>"Brown"</tt>). As we have seen
in the class definition,
<tt>new</tt> is a <i>class method</i> and can
only be called throughout its class. If object dynamic allocation fails,
the exception <tt>ooc_bad_alloc</tt> is thrown (see <a href="#Exceptions">Exceptions</a>).
The following line print the <tt>per</tt> object by <i>sending</i> the
<tt>print
</tt><i>message</i>
to the object
<tt>per</tt>. The command <tt>delete()</tt> is a special
macro which always delete properly an object by calling its destructor
and then freeing the object instance. If you need a function pointer to
<tt>delete()</tt>
(see
<a href="#Exceptions">Exceptions</a>), use <tt>ooc_delete()</tt> instead.
Obviously, messages can only be sent to properly initialized objects. It
is also possible to work with automatic objects to avoid dynamic allocation:
<blockquote><tt>t_person per[1] = { person.person() };</tt>
<br><tt>person.init(per, "Brown");</tt>
<br><tt><b>sendMsg</b>(per, print);</tt>
<br><tt>person._person(per);</tt></blockquote>
The first line initialize a new person <tt>per</tt> using the <i>object
constructor</i> <tt>person()</tt> automatically provided for each class
(see
<a href="#Interface">Interface</a>). Like for the <tt>new</tt> class
method, the constructor must be called throughout its class. After this
step, <tt>per</tt> is a well formed object, but not yet initialized and
this is done by the second line where the method
<tt>init</tt> is called
to initialize the object. The following line print the <tt>per</tt> object
by <i>sending</i> the appropriate
<i>message</i> to the object <tt>per</tt>.
Finally the object <tt>per</tt> is cleared but not deleted since it is
not a dynamically allocated object (automatic object). Basically, each
time you use an equivalent of <tt>new</tt> (resp. <tt>init</tt>) to create/initialize
an object, you probably must use <tt>delete</tt> (resp.
<tt>_<i>object</i></tt>)
to destroy this object before the end of its scope. <tt>init()</tt> is
a method and not a message since it is strongly related to the object type
and therefore will never be polymorphic.
<p>In the example above, we have declared <tt>per</tt> as an array to avoid
the <tt>&amp;</tt> in the macros. If your compiler complains about the
first line you can either do the initialization after the declaration or
use the following alternative:
<blockquote><tt>t_person per = person.person();</tt>
<br><tt>person.init(&amp;per, "Brown");</tt>
<br><tt><b>sendMsg</b>(&amp;per, print);</tt>
<br><tt>person._person(&amp;per);</tt></blockquote>
Dealing with array of automatic objects may be a little more complex:
<blockquote><tt>int i;</tt>
<br><tt>t_person per_ref = person.person();</tt>
<br><tt>t_person per[100];</tt>
<p><tt>for(i=0; i&lt;100; i++) {</tt>
<br><tt>&nbsp; memcpy(per +i, &amp;per_ref, sizeof(t_person));</tt>
<br><tt>&nbsp; person.init(per +i, "Unkown");</tt>
<br><tt>}</tt>
<p><tt>for(i=0; i&lt;100; i++) {</tt>
<br><tt><b>&nbsp; sendMsg</b>(per +i, print);</tt>
<br><tt>}</tt>
<p><tt>for(i=0; i&lt;100; i++) {</tt>
<br><tt>&nbsp; person._person(per +i);</tt>
<br><tt>}</tt></blockquote>
The use of <tt>memcpy()</tt> is required to cast away the constant specifier
of <tt>__vptr</tt> to avoid any objects bitwise copy. To allow such objects
copy (this assumes that you know what you do), you can compile your C files
with the flag <tt>-DALLOW_OBJCOPY</tt>. Then the statement <tt>per[i] =
per_ref;</tt> will become valid. The macro <tt>objCopy(obj1, obj2)</tt>
will be substituted by the assignment statement (i.e. <tt>obj1=obj2</tt>)
if
<tt>-DALLOW_OBJCOPY</tt> is specified or else by <tt>memcpy</tt>.(i.e.
<tt>memcpy(&amp;obj1,
&amp;obj2, sizeof(obj1))</tt>). Obviously, this macro waits for objects
instance, not objects addresses, to be able to compute objects size. If
automatic object array manipulation is important, it would be better to
write the <tt>initArr(size, args)</tt> and <tt>clearArr(size)</tt> methods
for this purpose.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Methods"></a><b><font face="Arial,Helvetica"><font size=+2>Methods</font></font></b></td>
</tr>
</table>

<p>If you know the <b><u>exact</u></b> class of an object, <i>sending</i>
a message can be replaced by the <i>call</i> of the object's method throughout
its class like for the methods and class methods. For example,
<blockquote><tt><b>sendMsg</b>(per, print);</tt></blockquote>
is equivalent to
<blockquote><tt><b>sendCMsg</b>(per, person, print);</tt></blockquote>
But beware that you can <b>involuntary call the wrong object method</b>
if for example it has been overloaded (see <a href="#Polymorphism">Polymorphism</a>).
That is why it is mainly reserved for the class implementation where usually
objects types are well known and where using object methods through their
class is the only way to bypass the polymorphism mechanism. Another safe
solution is:
<blockquote><tt><b>methodAddr</b>(per, print)(per);</tt></blockquote>
where <tt>methodAddr()</tt> returns a constant pointer to the object's
method, but <tt>per</tt> appears twice in the statement and it is not very
elegant comparing to the use of <tt>sendMsg()</tt>. To be complete, the
equivalent of the <tt>sendCMsg()</tt> used above would be:
<blockquote><tt><b>methodAddr</b>(&amp;person, print)(per);</tt></blockquote>
Note: messages and methods are function pointers and therefore can be used
as such.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Encapsulation"></a><b><font face="Arial,Helvetica"><font size=+2>Encapsulation</font></font></b></td>
</tr>
</table>

<p>Leaving objects members to public access can bring serious data integrity
problem like changing the stored size of an array without adjusting the
array size. One way to protect data and methods is to declare them as <tt>private</tt>.
Private members can only be accessed by their class or subclasses (see
<a href="#Inheritance">Inheritance</a>).
So it is wise to declare <tt>private</tt> all members that should not be
accessible by objects users.
<p>Private specification can be applied to the object data and methods
as well as to class data and methods. Sometimes, for simplicity or efficiency,
it is also useful to have direct access to object members like for the
complex number object:
<blockquote><tt>#define <b>OBJECT</b> complex</tt>
<p><b><tt>BASEOBJECT_INTERFACE</tt></b>
<p><tt>&nbsp; double <b>public</b>(real);</tt>
<br><tt>&nbsp; double <b>public</b>(imag);</tt>
<p><b><tt>BASEOBJECT_METHODS</tt></b>
<p><tt>&nbsp; /* no virtual function */</tt>
<p><b><tt>ENDOF_INTERFACE</tt></b></blockquote>
<i>Public</i> and <i>private</i> members and methods can be intermixed
without any problem. To reach a public member of an object, you do exactly
as for structures:
<blockquote><tt>t_complex *const j = complex.alloc();</tt>
<br><tt>j->m.imag = -1;</tt></blockquote>

<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Interface"></a><b><font face="Arial,Helvetica"><font size=+2>Interface</font></font></b></td>
</tr>
</table>

<p>The interface is simply where object and class definition take place,
usually in a header file (<tt><a href="examples/person.h">person.h</a></tt>)
which looks like:
<blockquote><tt>#ifndef PERSON_H</tt>
<br><tt>#define PERSON_H</tt>
<p><tt>#include &lt;ooc.h></tt>
<p><tt>#undef&nbsp; OBJECT</tt>
<br><tt>#define <b>OBJECT</b> person</tt>
<p><b><tt>BASEOBJECT_INTERFACE</tt></b>
<p><tt>&nbsp; char const* <b>private</b>(name);</tt>
<p><b><tt>BASEOBJECT_METHODS</tt></b>
<p><tt>&nbsp; void <b>constMethod</b>(print);</tt>
<p><b><tt>ENDOF_INTERFACE</tt></b>
<p><b><tt>CLASS_INTERFACE</tt></b>
<p><tt>&nbsp; t_person *const <b>classMethod_</b>(new) char const name[]
<b>__</b>;</tt>
<br><tt>&nbsp; void <b>method_</b>(init) char const name[] <b>__</b>;</tt>
<br><tt>&nbsp; void <b>method_</b>(copy) t_person const*const per __;</tt>
<p><b><tt>ENDOF_INTERFACE</tt></b>
<p><tt>#endif</tt></blockquote>
This file is split into two parts which describe the object and class definition
as seen before. One new thing to note is the inclusion of the header file
<tt>ooc.h
</tt>which
provides a set of useful keywords and macros like (<tt>BASE</tt>)<tt>OBJECT_INTERFACE</tt>,
(<tt>BASE</tt>)<tt>OBJECT_METHODS</tt>, (<tt>ABSTRACT</tt>)<tt>CLASS_INTERFACE</tt>
and
<tt>ENDOF_INTERFACE</tt> (see <a href="#Keywords">Keywords</a>). Macros
<tt>XXX_INTERFACE</tt>
delimit sections of the object and class interface definition. Another
thing is the declaration of
<tt>OBJECT</tt> as <tt>person</tt> which specifies
the class name for the interface and the implementation and creates automatically
the declaration <tt>t_OBJECT</tt> which is the generic name of the object
type (i.e. <tt>t_person</tt>, see <a href="#Genericity">Genericity</a>).
We also find the <tt>print</tt> method which prints a person's name. Since
<tt>print</tt>
does not change the object state, it is declared as a <i>constant object
method</i>.
<p>Once the <tt>person</tt> interface is properly defined and included
into your file, the following things are available:
<ul>
<li>
The <i>type</i> <tt>t_person</tt>. This is the <i>object type</i>.</li>

<li>
The <i>class</i> <tt>person</tt>. This is the <i>object class</i> itself
(instance).</li>

<li>
The <i>class method</i> <tt>person()</tt>. This is the object <i>constructor</i>.
A typical use is <tt>t_person per = person.person();</tt></li>

<li>
The <i>class method</i> <tt>alloc()</tt>. This is the object <i>allocator</i>.
A typical use is <tt>t_person *const per = person.alloc(); </tt>May throw
<tt>ooc_bad_alloc</tt>
exception.</li>

<li>
The <i>generic type</i> <tt>t_OBJECT</tt>. It is equivalent to <tt>t_person</tt>
except for genericity. Typically used in generic object interface and implementation.</li>
</ul>
In addition, the object designer must provide the already declared but
not defined destructor:
<ul>
<li>
The <i>method</i> <tt>_person()</tt>. This is the object <i>destructor</i>.
A typical use is <tt>person._person(per);</tt></li>
</ul>
Finally, it is very common to find the <tt>init</tt> (or variants) method:
<ul>
<li>
The <i>method</i> <tt>init()</tt>. This method does non-constant object
initialization, including dynamic initializations like arrays allocation
or string duplication. A typical use is <tt>person.init(per, "Brown");</tt></li>
</ul>
Finally, it is common to find (but not always, see <a href="#Abstract_Class">Abstract
Class</a>) the
<i>object factory</i> <tt>new</tt> (or variants) which most
of the time simply calls the allocator <tt>alloc()</tt> and the initializator
<tt>init()</tt>
with the new allocated object. That is why <tt>new()</tt> usually waits
for the same arguments as <tt>init()</tt>.
<p><b><u>Warning</u></b>: Do not confound the <tt>new()</tt> class method,
the allocator and the constructor! The constructor <tt><i>object</i>()</tt>
returns a well formed default object copy with all fields set to zero plus
static initialization specified in <tt>initClassDecl()</tt> (see <a href="#Implementation">Implementation</a>),
the allocator <tt>alloc()</tt> allocates an object and <i>calls the constructor</i>
and <tt>new()</tt> <i>calls the allocator</i> and <tt>init()</tt>.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Implementation"></a><b><font face="Arial,Helvetica"><font size=+2>Implementation</font></font></b></td>
</tr>
</table>

<p>The implementation is the hidden side of the class. Only class designers
are concerned by the class implementation which take place into a separate
C file (<tt><a href="examples/person.c">person.c</a></tt>) with the same
name as the class interface header file (<tt><a href="examples/person.h">person.h</a></tt>).
A good advise would be to always design entirely the interface first and
then to program the implementation. This should help you to concentrate
on object data and methods which is the most important part of your class
and to postpone technical problems at development time. It is time now
to have a look to the implementation:
<blockquote><tt>#include &lt;stdio.h></tt>
<p><tt>#define <b>IMPLEMENTATION</b></tt>
<p><tt>#include &lt;person.h></tt>
<p><tt>void</tt>
<br><tt><b>constMethodDecl</b>(print)</tt>
<br><tt>{</tt>
<br><tt>&nbsp; printf("name:\t%s\n", <b>this</b>->m.name);</tt>
<br><tt>}</tt>
<p><b><tt>BASEOBJECT_IMPLEMENTATION</tt></b>
<p><tt>&nbsp; <b>methodName</b>(print)</tt>
<p><b><tt>ENDOF_IMPLEMENTATION</tt></b>
<p><tt><b>initClassDecl</b>() {} /* class ctor, required */</tt>
<p><tt><b>dtorDecl</b>() /* object dtor, required */</tt>
<br><tt>{</tt>
<br><tt>&nbsp; free((void*)<b>this</b>->m.name);</tt>
<br><tt>&nbsp; <b>this</b>->m.name = NULL;</tt>
<br><tt>}</tt>
<p><tt>t_person</tt>
<br><tt><b>classMethodDecl_</b>(*const new) char const name[] <b>__</b></tt>
<br><tt>{</tt>
<br><tt>&nbsp; t_person *const this = person.alloc();</tt>
<br><tt>&nbsp; person.init(this, name);</tt>
<br><tt>&nbsp; return this;</tt>
<br><tt>}</tt>
<p><tt>void</tt>
<br><tt><b>methodDecl_</b>(init) char const name[] <b>__</b></tt>
<br><tt>{</tt>
<br><tt>&nbsp; <b>this</b>->m.name = strdup(name);</tt>
<br><tt>}</tt>
<p><tt>void</tt>
<br><tt><b>methodDecl_</b>(copy) t_person const*const per <b>__</b></tt>
<br><tt>{</tt>
<br><tt>&nbsp; person._person(<b>this</b>);</tt>
<br><tt>&nbsp; person.init(<b>this</b>, per->m.name);</tt>
<br><tt>}</tt>
<p><b><tt>CLASS_IMPLEMENTATION</tt></b>
<p><tt>&nbsp; methodName(new),</tt>
<br><tt>&nbsp; methodName(init),</tt>
<br><tt>&nbsp; methodName(copy)</tt>
<p><b><tt>ENDOF_IMPLEMENTATION</tt></b>
<br>&nbsp;</blockquote>
The file starts by the definition of the keyword <tt>IMPLEMENTATION</tt>
followed by the inclusion of the person interface. It is important to include
<tt>person.h
</tt><b><u>after</u></b>
the <tt>IMPLEMENTATION</tt> definition otherwise its content would be different
and you would not be able to reach the object private member <tt>name</tt>
or to use most of the keywords displayed in bold in the listing above.
<p>Then follows the object methods definitions. The use of the keyword
<tt>methodDecl</tt>,
<tt>constMethodDecl</tt>
and <tt>classMethodDecl</tt> helps to declare correctly the methods, the
constant object methods and the class methods. All methods have the storage
class specifier <tt>static</tt> which guarantees the encapsulation of the
methods into the implementation module (i.e. the file). Since the
<tt>static</tt>
storage specifier is included into the
<tt>methodDecl</tt>, <tt>constMethodDecl</tt>
and <tt>classMethodDecl</tt> macros, pointers qualifier <tt>*</tt> and
<tt>const</tt>
have to be put with the method name, not with the returned type (i.e. <tt>char
methodDecl(*const getName);</tt>). A clean solution to avoid this little
annoyance is to define the returned pointer type with
<tt>typedef</tt>
locally to the implementation. Macros
<tt>methodDecl</tt>,
<tt>constMethodDecl</tt>
and <tt>classMethodDecl
</tt>have their equivalent version with variable
number of arguments: <tt>methodDecl_</tt>,
<tt>constMethodDecl_</tt> and
<tt>classMethodDecl_</tt>.
<p>Then follows the object implementation delimited by <tt>(BASE)OBJECT_IMPLEMENTATION</tt>
and
<tt>ENDOF_IMPLEMENTATION</tt> and inside these tags you find the list
of the object methods <b>in the same order as declared in the object methods
interface</b>. Whatever, the compiler will complain if the order is not
respected (except if two successive methods have the same prototype!).
<p>Then follows the <i>required</i> <tt>initClassDecl()</tt> declaration
which is a special local function where class initializations are done
like default object initialization (returned by the constructor), superclasses
initialization (see <a href="#Inheritance">Inheritance</a>) or functions
overloading (see <a href="#Polymorphism">Polymorphism</a>). <i>Default
static object</i> initializations can be achieved by assigning default
values (by default all fields are set to zero) to members using <tt>objDefault()</tt>
(i.e. <tt>objDefault(level) = 1;</tt> in <tt><a href="examples/manager.c">manager.c</a></tt>).
The destructor <tt>_person()</tt> declared by <tt>dtorDecl()</tt> is always
<i>required</i>
even if it is empty like <tt>initClassDecl()</tt> is this example.
<p>Then follows the methods and class methods definitions. Again the method
declarations are done with the
<tt>methodDecl</tt>,
<tt>constMethodDecl</tt>
and <tt>classMethodDecl</tt> macros. The class method <tt>new</tt> looks
99% of the time like this one, that is calling the allocator and initializing
the new object.
<p>Finally, the class implementation is delimited by <tt>CLASS_IMPLEMENTATION</tt>
and
<tt>ENDOF_IMPLEMENTATION</tt> and inside these tags you find the list
of the methods and class methods <b>in the same order as declared in the
class interface</b>. Whatever, the compiler will complain if the order
is not respected (except if two successive methods have the same prototype!).
<p>The section <tt>(BASE)OBJECT_IMPLEMENTATION</tt> and <tt>(ABSTRACT)CLASS_IMPLEMENTATION</tt>
can be declared at the top of the file if you provide the methods prototypes
before. It may significantly improve the readability of big implementation.
<p>Note: Inside <i>methods and object methods</i>, the <b>current object
is always called
<tt>this</tt></b> (C++: member function and <tt>this</tt>
pointer). It is a pointer to constant object if the method has been declared
as a constant method (C++: constant member function).
<p>Note: If your libc does not provide the non-C89 <tt>strdup()</tt> function,
your can use the one provided in <tt>ooc.c</tt> by compiling your programs
with the flag <tt>-DALLOW_STRDUP</tt>.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Inheritance"></a><b><font face="Arial,Helvetica"><font size=+2>Inheritance</font></font></b></td>
</tr>
</table>

<p>Up to now, we have seen how to define base objects which do not inherit
from other objects. But without inheritance you cannot reuse already implemented
objects or split your project into smaller entities like OOP requires.
Since we need at least another object, we create the specialized subclass
<tt>employee</tt>
from the class <tt>person</tt>. As in real life, an employee is a person
to which we add a departement information. So we derive <tt>employee
</tt>from
<tt>person</tt>.
Person viewed from employee becomes a <i>superclass</i>. Here is the employee
interface (<tt><a href="examples/employee.h">employee.h</a></tt>):
<blockquote><tt>#ifndef EMPLOYEE_H</tt>
<br><tt>#define EMPLOYEE_H</tt>
<p><tt>#include &lt;person.h></tt>
<p><tt>#undef&nbsp; OBJECT</tt>
<br><tt>#define <b>OBJECT</b> employee</tt>
<p><b><tt>OBJECT_INTERFACE</tt></b>
<p><tt>&nbsp; <b>INHERIT_MEMBERS_OF</b> (person);</tt>
<br><tt>&nbsp; char const* <b>private</b>(department);</tt>
<p><b><tt>OBJECT_METHODS</tt></b>
<p><tt>&nbsp; <b>INHERIT_METHODS_OF</b> (person);</tt>
<p><b><tt>ENDOF_INTERFACE</tt></b>
<p><b><tt>CLASS_INTERFACE</tt></b>
<p><tt>&nbsp; t_employee*const <b>classMethod_</b>(new) char const name[],
char const department[] __;</tt>
<br><tt>&nbsp; void <b>method_</b>(init) char const name[], char const
department[] __;</tt>
<br><tt>&nbsp; void <b>method_</b>(copy) t_employee const*const emp __;</tt>
<p><b><tt>ENDOF_INTERFACE</tt></b>
<p><tt>#endif</tt></blockquote>
The listing above shows how it is simple to derive your class from one
or more superclasses. First you need to include the interface of the superclass.
Then you define the class name, the object interface and the class interface
as we have seen before (see <a href="#Interface">Interface</a>). The inheritance
is built by the declarations <tt>INHERIT_MEMBERS_OF()</tt> and <tt>INHERIT_METHODS_OF()</tt>
in the object definition delimited by <tt>OBJECT_INTERFACE</tt> and <tt>OBJECT_METHODS</tt>.
Inheritance declaration must always be placed <b>at the beginning</b> of
these sections. As you can see, the <tt>BASE</tt> prefix disappeared from
these tags since <tt>employee</tt> is not a <i>base object</i> but a derived
object.
<p>The inheritance declarations in implementation are as simple as for
the interface (<tt><a href="examples/employee.c">employee.c</a></tt>):
<blockquote><tt>#include &lt;stdio.h></tt>
<p><tt>#define <b>IMPLEMENTATION</b></tt>
<p><tt>#include &lt;employee.h></tt>
<p><tt>void</tt>
<br><tt><b>constMethodOvldDecl</b>(print, person)</tt>
<br><tt>{</tt>
<br><tt>&nbsp; <b>sendCMsg</b>(<b>this</b>, person, print);</tt>
<br><tt>&nbsp; /* sub_cast() downcast this from person to employee */</tt>
<br><tt>&nbsp; printf("\tdept:\t%s\n", <b>sub_cast</b>(this,person)->m.department);</tt>
<br><tt>}</tt>
<p><b><tt>OBJECT_IMPLEMENTATION</tt></b>
<p><tt>&nbsp; <b>SUPERCLASS</b>(person)</tt>
<p><b><tt>ENDOF_IMPLEMENTATION</tt></b>
<p><tt><b>initClassDecl</b>() /* class ctor, required */</tt>
<br><tt>{</tt>
<br><tt>&nbsp; <b>initSuper</b>(person);</tt>
<br><tt>&nbsp; <b>overload</b>(person.print) = <b>methodOvldName</b>(print,
person);</tt>
<br><tt>}</tt>
<p><tt><b>dtorDecl</b>() /* object dtor, required */</tt>
<br><tt>{</tt>
<br><tt>&nbsp; person._person(<b>super</b>(<b>this</b>,person)); /* upcast
*/</tt>
<br><tt>&nbsp; free((void*)<b>this</b>->m.department);</tt>
<br><tt>&nbsp; <b>this</b>->m.department = NULL;</tt>
<br><tt>}</tt>
<p><tt>t_employee</tt>
<br><tt><b>classMethodDecl_</b>(*const new) char const name[], char const
department[] <b>__</b></tt>
<br><tt>{</tt>
<br><tt>&nbsp; t_employee *const this = employee.alloc();</tt>
<br><tt>&nbsp; employee.init(this, name, department);</tt>
<br><tt>&nbsp; return this;</tt>
<br><tt>}</tt>
<p><tt>void</tt>
<br><tt><b>methodDecl_</b>(init) char const name[], char const department[]
<b>__</b></tt>
<br><tt>{</tt>
<br><tt>&nbsp; /* super() upcast this from employee to person */</tt>
<br><tt>&nbsp; person.init(<b>super</b>(<b>this</b>,person), name);</tt>
<br><tt>&nbsp; <b>this</b>->m.department = strdup(department);</tt>
<br><tt>}</tt>
<p><tt>void</tt>
<br><tt><b>methodDecl_</b>(copy) t_employee const*const emp <b>__</b></tt>
<br><tt>{</tt>
<br><tt>&nbsp; employee._employee(<b>this</b>);</tt>
<br><tt>&nbsp; employee.init(<b>this</b>, emp->m.person.m.name, emp->m.department);</tt>
<br><tt>}</tt>
<p><b><tt>CLASS_IMPLEMENTATION</tt></b>
<p><tt>&nbsp; <b>methodName</b>(new),</tt>
<br><tt>&nbsp; <b>methodName</b>(init),</tt>
<br><tt>&nbsp; <b>methodName</b>(copy)</tt>
<p><b><tt>ENDOF_IMPLEMENTATION</tt></b></blockquote>
The <tt>SUPERCLASS</tt> macro declares <tt>person</tt> as a superclass
of <tt>employee</tt>. Like for the methods declarations, it must appear
in the same order and place as in the beginning of the interface definition.
The <tt>initClassDecl()</tt> which this time is not empty, is automatically
called <b><u>once</u></b> by the constructor to properly initialize the
superclass <tt>person</tt> and therefore guarantee the validity of the
<tt>employee</tt>
class. The rest of the file looks like the person implementation adapted
for employee, it means that employee
<tt>init()</tt> and <tt>_employee()</tt>
class methods call first the person <tt>init()</tt> and
<tt>_person()</tt>
class methods. Finally the overloaded <tt>print</tt> object method of person
(same slot in <tt>vtbl</tt>) <i>calls</i> the person <tt>print</tt> methodand
display information related to employee only (i.e. the department). Since
no new object method has been defined for employee, the size of the virtual
table of <tt>employee</tt> is the same as the size of the virtual table
of <tt>person</tt>.
<p>The <tt>super</tt> macro (equivalent to <tt>super_cast()</tt>) used
in the methods implementation above <i>upcast </i><tt>this</tt> which is
an employee (<tt>t_employee</tt>) to a person (<tt>t_person</tt>). Every
time you need to <i>send a message</i> or <i>call a method</i> of a <i>superclass</i>,
you must use <tt>super(<i>object</i>, <i>superclass</i>)</tt> to upcast
the object into a <i>superobject</i>. Since a class may inherit from several
superclasses (see <a href="#Multiple_Inheritance">Multiple Inheritance</a>),
the full member name (without the first <tt>m</tt>) of the superclass must
be provided. To reach a <i>superobject</i> public members of an object,
you do exactly as for normal class:
<blockquote><tt><b>super</b>(<i>object</i>, <i>super</i>)->m.<i>public_member</i></tt>.</blockquote>
The <tt>sub_cast()</tt> macro used in the methods implementation above
<i>downcast</i><tt>this</tt>
which is a person (<tt>t_person</tt>) to an employee (<tt>t_employee</tt>).
Every time you need to reach the <i>subclass</i> in its implementation,
you must use <tt>sub_cast(<i>object</i>, <i>superclass</i>)</tt> to downcast
the <i>superobject</i> into the implemented object. Since the subclass
may inherit from several superclasses (see <a href="#Multiple_Inheritance">Multiple
Inheritance</a>), the full member name (without the first <tt>m</tt>) of
the superclass must be provided. To reach the <i>subobject</i> public members
of an object, you can do:
<blockquote><tt><b>sub_cast</b>(<i>object</i>, <i>super</i>)->m.<i>public_member</i></tt>.</blockquote>
In fact, <tt>sub_cast()</tt> is only available in implementation and refers
to the definition of <tt>OBJECT</tt> to know the subclass name.
<p>To summarize, <tt>super_cast()</tt> (or <tt>super()</tt>) upcast a subclass
to a superclass while <tt>sub_cast()</tt> downcast a superclass to the
<tt>OBJECT</tt>
subclass. Both are static cast resolved a compilation time.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Multiple_Inheritance"></a><b><font face="Arial,Helvetica"><font size=+2>Multiple
Inheritance</font></font></b></td>
</tr>
</table>

<p>Multiple inheritance can be easily achieved in the same way as single
inheritance (see <a href="#Inheritance">Inheritance</a>) by duplicating
approprialty <tt>INHERIT_MEMBERS_OF()</tt>, <tt>INHERIT_METHODS_OF()</tt>,
<tt>SUPERCLASS()</tt>
and <tt>initSuper()</tt> definition and declarations. Assuming the existence
of the superclasses
<tt>class1</tt>,
<tt>class2</tt> and of the class <tt>aClass</tt>
which inherits from both superclasses. Starting from single inheritance,
some modifications have to be done in interface:
<blockquote><tt>#ifndef ACLASS_H</tt>
<br><tt>#define ACLASS_H</tt>
<p><tt>#include &lt;class1.h></tt>
<br><tt>#include &lt;class2.h></tt>
<p><tt>#undef&nbsp; OBJECT</tt>
<br><tt>#define <b>OBJECT</b> aClass</tt>
<p><b><tt>OBJECT_INTERFACE</tt></b>
<p><tt>&nbsp; <b>INHERIT_MEMBERS_OF</b> (class1);</tt>
<br><tt>&nbsp; <b>INHERIT_MEMBERS_OF</b> (class2);</tt>
<br><tt>&nbsp; ...</tt>
<br><b><tt>OBJECT_METHODS</tt></b>
<p><tt>&nbsp; <b>INHERIT_METHODS_OF</b> (class1);</tt>
<br><tt>&nbsp; <b>INHERIT_METHODS_OF</b> (class2);</tt>
<br><tt>&nbsp; ...</tt>
<br><b><tt>ENDOF_INTERFACE</tt></b>
<br>&nbsp;
<p><b><tt>CLASS_INTERFACE</tt></b>
<br><tt>&nbsp; ...</tt>
<br><b><tt>ENDOF_INTERFACE</tt></b>
<p><tt>#endif</tt></blockquote>
as well as in implementation:
<blockquote><tt>...</tt>
<br><b><tt>OBJECT_IMPLEMENTATION</tt></b>
<p><tt>&nbsp; <b>SUPERCLASS</b> (class1),</tt>
<br><tt>&nbsp; <b>SUPERCLASS</b> (class2),</tt>
<br><tt>&nbsp; ...</tt>
<br><b><tt>ENDOF_IMPLEMENTATION</tt></b>
<p><tt><b>initClassDecl</b>()</tt>
<br><tt>{</tt>
<br><tt>&nbsp; ...</tt>
<br><tt>&nbsp; <b>initSuper</b>(class1);</tt>
<br><tt>&nbsp; <b>initSuper</b>(class2);</tt>
<br><tt>&nbsp; ...</tt>
<br><tt>}</tt>
<br><tt>...</tt>
<br><b><tt>CLASS_IMPLEMENTATION</tt></b>
<br><tt>&nbsp; ...</tt>
<br><b><tt>ENDOF_IMPLEMENTATION</tt></b></blockquote>
And that is all. As previously mentioned, superclasses declaration must
be done at the beginning of each section of the object interface and must
be at the same place in the object implementation. Sending a message to
a superclass is identical to single inheritance:
<blockquote><tt><b>sendMsg</b>(<b>super</b>(<i>object</i>, <i>superclass</i>),
<i>message</i>);</tt></blockquote>
If you inherit twice (two levels of inheritance), you should do:
<blockquote><tt><b>sendMsg</b>(<b>super</b>(<i>object</i>, <i>superclass.m.supersuperclass</i>),
<i>message</i>);</tt></blockquote>
and so on. The advantage of specifying the superclass name is that you
can choose which superclass receives the message (two superclasses may
answer to the same message).
<p>But it can become quickly boring to use <tt>super()</tt> each time you
have to send a message to your superclasses, or you may want to send the
same message to all your superclasses at the same time. In that case, the
best thing to do is to declare in your <tt>aClass</tt> a method using the
same name (i.e. <tt>the_message</tt>) with a declaration which should look
like:
<blockquote><tt>void</tt>
<br><tt><b>methodDecl</b>(the_message)</tt>
<br><tt>{</tt>
<br><tt>&nbsp; <b>sendCMsg</b>(<b>super</b>(this,class1),class1,the_message);</tt>
<br><tt>&nbsp; <b>sendCMsg</b>(<b>super</b>(this,class2),class2,the_message);</tt>
<br><tt>}</tt></blockquote>
Now, assuming <i><tt>object</tt></i> to be of class <tt>aClass</tt>,
<tt>sendMsg(<i>object</i>,
the_message);</tt> in a program will send automatically the correct message
to all your
<br>superclasses. This way of doing respects the polymorphism (if any,
see <a href="#Polymorphism">Polymorphism</a>) of your class and of its
superclasses.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Polymorphism"></a><b><font face="Arial,Helvetica"><font size=+2>Polymorphism</font></font></b></td>
</tr>
</table>

<p>The polymorphism is the aptitude of an object to be used as another
object while keeping its original behavior. This section assume the following
inheritance hierarchy:
<blockquote><tt>manager --> employee --> person</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --> education</tt></blockquote>
where <tt>--></tt> indicates the class derivation. For a complete interface
and implementation of these objects see <tt><a href="examples/person.h">person.h</a></tt>,
<tt><a href="examples/person.c">person.c</a></tt>,
<tt><a href="examples/employee.h">employee.h</a></tt>,
<tt><a href="examples/employee.c">employee.c</a></tt>,
<tt><a href="examples/education.h">education.h</a></tt>,
<tt><a href="examples/education.c">education.c</a></tt>,
<tt><a href="examples/manager.h">manager.h</a></tt>
and
<tt><a href="examples/manager.c">manager.c</a></tt>.
<p>One important thing in these classes is the overload of their <tt>print</tt>
method, like for the manager example:
<blockquote><tt>void</tt>
<br><tt><b>constMethodOvldDecl</b>(print, person)</tt>
<br><tt>{</tt>
<br><tt>&nbsp; /* this is a person */</tt>
<br><tt>&nbsp; /* send the print person message to this as an employee
*/</tt>
<br><tt>&nbsp; <b>sendCMsg</b>(this, employee, person.print);</tt>
<br><tt>&nbsp; /* send the print person message to this as an education
*/</tt>
<br><tt>&nbsp; <b>sendCMsg</b>(<b>super</b>(<b>sub_cast</b>(this,employee.m.person),education),education,print);</tt>
<br><tt>&nbsp; printf("\tlevel:\t%d\n", <b>sub_cast</b>(this,employee.m.person)->m.level);</tt>
<br><tt>}</tt>
<p><tt>...</tt>
<p><tt><b>initClassDecl</b>()</tt>
<br><tt>{</tt>
<br><tt>&nbsp; <b>initSuper</b>(employee);</tt>
<br><tt>&nbsp; <b>initSuper</b>(education);</tt>
<br><tt><b>&nbsp; overload</b>(employee.person.print) = <b>methodOvldName</b>(print,
person);</tt>
<br><tt>&nbsp; ...</tt>
<br><tt>}</tt></blockquote>
This overloading mechanism change the manager virtual table slot <tt>employe.person.print</tt>
which initially points to the person <tt>print</tt> message, to pointing
to the <tt>print</tt> message defined above. This new message call the
<tt>print</tt>
message of the <tt>employee</tt> and <tt>education</tt> classes using <tt>sendCMsg()</tt>
to avoid infinite loop and then print information related to <tt>manager</tt>.
Inside implementation, as you can see, you can change from one superclass
to another by using a combination of <tt>sub_cast()</tt> and <tt>super_cast()</tt>.
Outside implementation you have to either use <tt>static_cast(this, employee.m.person,
manager)</tt> (unsafe) and use <tt>super_cast()</tt> to get the superclass
or to use <tt>dynamic_cast(this, education)</tt>. The latter is slower
but safe since it behaves exactly as the C++ <tt>dynamic_cast</tt> operator.
<p>The following example shows how to display all information of a person
whatever it is a person, an employee or a manager (see <tt><a href="examples/test_manager.c">test_manager.c</a></tt>
for a complete example). The small program:
<blockquote><tt>#include &lt;manager.h></tt>
<p><tt>void print_person(t_person *const per)</tt>
<br><tt>{</tt>
<br><tt>&nbsp; <b>sendMsg</b>(per, print);</tt>
<br><tt>}</tt>
<p><tt>int main(void)</tt>
<br><tt>{</tt>
<br><tt>&nbsp; t_person&nbsp;&nbsp; *const per = person&nbsp; .new("Brown");</tt>
<br><tt>&nbsp; t_employee *const emp = employee.new("Smith", "Cars");</tt>
<br><tt>&nbsp; t_manager&nbsp; *const mng = manager .new("Collins", "Trucks",
"PhD", 2);</tt>
<p><tt>&nbsp; print_person(per);</tt>
<br><tt>&nbsp; print_person(<b>super</b>(emp,person));</tt>
<br><tt>&nbsp; print_person(<b>super</b>(mng,employee.m.person));</tt>
<p><tt>&nbsp; <b>delete</b>(per);</tt>
<br><tt>&nbsp; <b>delete</b>(emp);</tt>
<br><tt>&nbsp; <b>delete</b>(mng);</tt>
<p><tt>&nbsp; return EXIT_SUCCESS;</tt>
<br><tt>}</tt></blockquote>
will gives the output:
<blockquote><tt>name: Brown</tt>
<br><tt>name: Smith</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dept: Cars</tt>
<br><tt>name: Collins</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dept: Trucks</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dipl: PhD</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; level: 2</tt></blockquote>
and we see that the function <tt>print_employee() </tt>does not need distinguish
a person from an employee or a manager. The polymorphism is achieved by
the message <tt>print</tt> in the function <tt>print_person</tt>. Using
<tt>sendMsg()</tt>
always ensures to refer to the right virtual table (through
<tt>__vptr</tt>)
and therefore to call the appropriate object method.
<p>To simplify polymorphism implementation, <tt>ooc.h</tt> also provides
few interesting macros:
<ul>
<li>
<tt>className(<i>object</i>)</tt> returns a constant string which contains
the name of the object's class.</li>

<li>
<tt>isA(<i>object</i>, <i>class</i>)</tt> returns a non-zero value if <i><tt>object</tt></i>
is of class <i><tt>class</tt></i>.</li>

<li>
<tt>offsetOf(<i>object</i>)</tt> returns the <tt>size_t</tt> offset of
<i><tt>object</tt></i>
inside its subobject (if any).</li>

<li>
<tt>typeid(<i>object</i>)</tt> returns a pointer to the <i><tt>object</tt></i>
RTTI.</li>

<li>
<tt>methodAddr(<i>object</i>, <i>message</i>)</tt> returns a function pointer
to the <i><tt>object</tt></i> <i><tt>message</tt></i>.</li>

<li>
<tt>super_cast(<i>object</i>, <i>superclass</i>)</tt> <i>upcast</i> <i><tt>object</tt></i>
to <i><tt>superclass</tt></i> (also available as <tt>super()</tt>).</li>

<li>
<tt>base_cast(<i>object</i>)</tt> <i>downcast</i> <i><tt>object</tt></i>
to its bigger subclass. Returns an untyped pointer.</li>

<li>
<tt>static_cast(<i>object</i>, <i>class</i>, <i>subclass</i>)</tt> <i>downcast<tt>object</tt></i>
from <i><tt>class</tt></i> to <i><tt>subclass</tt></i> (unsafe).</li>

<li>
<tt>dynamic_cast(<i>object</i>, <i>class</i>)</tt> cast <i><tt>object</tt></i>
to <i><tt>class</tt></i> or returns <tt>NULL</tt> (C++: <tt>dynamic_cast</tt>,
safe).</li>

<li>
<tt>sub_cast(<i>object</i>, <i>class</i>)</tt> equivalent to <tt>static_cast(<i>object</i>,
<i>class</i>,
OBJECT)</tt> (only available in implementation).</li>

<li>
<tt>overload(<i>object</i>, <i>method</i>)</tt> returns the virtual table
slot of <i><tt>method</tt></i> (only available in implementation).</li>
</ul>
We also find the <tt>constMethodOvldDecl(<i>method, super</i>)</tt> and
<tt>methodOvldName(<i>method,
super</i>)</tt> macros which are the sisters of <tt>constMethodDecl(<i>method</i>)</tt>
and
<tt>methodName(<i>method</i>)</tt> used to declare overloading superclass
methods.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Abstract_Class"></a><b><font face="Arial,Helvetica"><font size=+2>Abstract
Class</font></font></b></td>
</tr>
</table>

<p>Abstract classes are commonly used to defined a common object interface
for a set of objects. They rarely implement the services they declare (set
to zero). These services must therefore be implemented by the subclasses
and message passing resolution will be done by the polymorphism mechanism.
<i>Abstract
classes</i> are classes without object factory like <tt>alloc()</tt> or
<tt>new()</tt>
or with an incomplete set of messages. <i>Pure abstract classes</i> are
classes without implementation (not supported by OOPC).
<p>The abstract class interface must be declared with <tt>ABSTRACTCLASS_INTERFACE</tt>
and the implementation must be declared with <tt>ABSTRACTCLASS_IMPLEMENTATION</tt>.
The allocator (<tt>alloc()</tt>) is not available and therefore is it not
possible to implement object factory (see memBlock in <a href="#Examples">Examples</a>).
Constructor (<tt><i>object</i>()</tt>) and destructor (<tt><i>_object</i>()</tt>)
are still available.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Genericity"></a><b><font face="Arial,Helvetica"><font size=+2>Genericity</font></font></b></td>
</tr>
</table>

<p>Genericity can partially be performed with polymorphism at the level
of object or with a combination of untyped pointer (<tt>void*</tt>) and
<tt>isA()</tt>
tests at the level of functions. But to write objects independently of
data types like the C++ allows with templates, we need to introduce some
programming techniques. The principle is based on the use of <i>defined
generic types</i> like <tt>gType1</tt>, <tt>gType2</tt>, etc... in place
of specialized types in objects and classes interfaces and implementations.
Specialization of objects and classes is postpone at the user level according
to its needs.
<p>To simplify the transition between specialized code and generic code
you can follow the step by step procedure below. Examples are based on
the generic <tt>memBlock</tt> and <tt>array</tt> (which inherit from <tt>memBlock</tt>)
classes (see <a href="#Examples">Examples</a>):
<p><b>Generalization (designer)</b>
<ol>
<li>
Build and test specialized (i.e. <tt>double</tt>) objects and classes (i.e.
<tt>array</tt>).</li>

<li>
[Interface only] Replace the header top line <tt>#ifndef <i>CLASS</i>_H</tt>
by (i.e. <tt><i>CLASS</i> == ARRAY</tt>):</li>

<br><tt>#if define(<b>GENERIC</b>) || !define(G_<i>CLASS_</i>H)</tt>
<li>
[Interface only] Replace <tt>#define OBJECT <i>object</i></tt> by&nbsp;
(i.e. <tt><i>object</i> == array</tt>):</li>

<br><tt>#define <b>OBJECT</b> <b>GENERIC</b>(<i>object</i>)</tt>
<li>
Replace <i><tt>object</tt></i> by <tt>OBJECT</tt> everywhere (i.e. <tt>array</tt>
by <tt>OBJECT</tt>). It should also replace <tt>t_<i>object</i></tt> by
<tt>t_OBJECT</tt>
everywhere (i.e. <tt>t_array</tt> by <tt>t_OBJECT</tt>) since it is a substring.</li>

<li>
Replace <i><tt>super</tt> </i>by <tt>GENERIC(<i>super</i>)</tt> everywhere
(i.e. <tt>memBlock</tt> by <tt>GENERIC(memBlock)</tt> and <tt>_memBlock</tt>
by <tt>GENERIC_DTOR(memBlock)</tt>).&nbsp; In implementation you can <tt>#define
MEMBLOCK GENERIC(memBlock)</tt> and <tt>#define _MEMBLOCK GENERIC_DTOR(memBlock)</tt>
and use <tt>MEMBLOCK</tt> and <tt>_MEMBLOCK</tt> everywhere to make code
more readable.</li>

<li>
Replace specialized types by generic types <tt>gType1,</tt> <tt>gType2,...</tt>
(i.e. <tt>gType1 == double</tt>)</li>
</ol>
<b>Specialization (user)</b>
<ol>
<li>
Create a specialized interface (i.e. <tt><a href="examples/array.h">array.h</a></tt>)
based on the following model (assuming that <tt><a href="examples/g_array.h">g_array.h</a></tt>
is the generic interface):</li>

<br><tt>#define <b>gTypePrefix</b> d</tt>
<br><tt>#define <b>gType1</b> double</tt>
<br><tt>#include &lt;g_array.h></tt>
<br><tt>#undef <b>gType1</b></tt>
<br><tt>#undef <b>gTypePrefix</b></tt>
<li>
Create a specialized implementation (i.e. <tt><a href="examples/array.c">array.c</a></tt>)
based on the following model (assuming that <tt><a href="examples/g_array.c">g_array.c</a></tt>
is the generic implementation):</li>

<br><tt>#define <b>gTypePrefix</b> d</tt>
<br><tt>#define <b>gType1</b> double</tt>
<br><tt>#include &lt;g_array.c></tt></ol>
After having applied these steps (it takes few minutes) to build up specialized
version of your generic code, the new specialized objects and classes with
the <tt>gTypePrefix</tt> concatenated in front of their names (i.e. object
<tt>t_darray</tt>
and class <tt>darray</tt>) are ready to use. Have a look to the memBlock
and array examples for more details (see
<a href="#Examples">Examples</a>).
You can also read the documentation
<a href="http://home.cern.ch/ldeniau/docs/gencode.pdf">Writing
generic code in C and C++</a> for more complex applications.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Exceptions"></a><b><font face="Arial,Helvetica"><font size=+2>Exceptions</font></font></b></td>
</tr>
</table>

<p>An exception is a mechanism for handling errors in a different way than
returning special values or setting global variables. The exceptions use
the same philosophy as OOP techniques, that means solving the problem where
you have the knowledge for. The advantages are on the object user side,
you do not care where exceptions (errors) are trigged and therefore you
do not need to check all the values returned by the called functions. You
may catch the exceptions in your program and solve the problem at the appropriate
place. On the object programmer side, you don't care how to answer to an
exception and where to go after. You just throw the exception (error) and
it is up to the user to catch it or not.
<p>To use exceptions, you need to include the header file <tt><a href="exception.h">exception.h</a></tt>
and to link the file <tt><a href="exception.c">exception.c</a></tt> in
your project. Then exceptions are ready to use more or less like in C++:
<ul>
<li>
<tt>try { <i>statements</i> }</tt> tries to execute the block enclosed
into the braces.</li>

<li>
<tt>catch(<i>exception</i>) { <i>statements</i> }</tt> executes the instructions
enclosed into the braces if <i><tt>exception</tt></i> has been thrown during
the execution of the previous <tt>try</tt> block.</li>

<li>
<tt>catch_any { <i>statements</i> }</tt> executes the instructions enclosed
into the braces if an uncaught exception has been thrown during the execution
of the previous <tt>try</tt> block.</li>

<li>
<tt>endtry</tt> closes the previous <tt>try</tt>.</li>

<li>
<tt>throw(<i>exception</i>)</tt> throws the exception <i><tt>exception</tt></i>.</li>

<li>
<tt>exception</tt> is the current exception identifier (integer value)
available in the <tt>catch_any</tt> block. Useful to propagate unprocessed
exceptions.</li>

<li>
<tt>protectPtr(<i>pointer</i>, <i>pointer_free</i>)</tt> protects dynamically
allocated memory against exceptions.</li>

<li>
<tt>unprotectPtr(<i>pointer</i>)</tt> unprotects protected pointers against
exceptions. Does not free the memory.</li>
</ul>
The best way to understand the use of exceptions is to learn from example:
<blockquote><tt>#include &lt;stdio.h></tt>
<br><tt>#include &lt;math.h></tt>
<br><tt>#include &lt;exception.h></tt>
<p><tt>/* can also be #defined */</tt>
<br><tt>enum { no_exception, zero_divide, domain_error, bad_alloc } exceptions;</tt>
<p><tt>double div_(double a, double b)</tt>
<br><tt>{</tt>
<br><tt>&nbsp; if (b == 0.0) <b>throw</b>(zero_divide);</tt>
<br><tt>&nbsp; return a/b;</tt>
<br><tt>}</tt>
<p><tt>double ln_(double a)</tt>
<br><tt>{</tt>
<br><tt>&nbsp; if (a &lt;= 0.0) <b>throw</b>(domain_error);</tt>
<br><tt>&nbsp; return log(a);</tt>
<br><tt>}</tt>
<p><tt>int main(void)</tt>
<br><tt>{</tt>
<br><tt>&nbsp; double a, b;</tt>
<p><tt>&nbsp; printf("a = "); scanf("%lf", &amp;a);</tt>
<br><tt>&nbsp; printf("b = "); scanf("%lf", &amp;b);</tt>
<p><tt>&nbsp; <b>try</b> {</tt>
<br><tt>&nbsp;&nbsp;&nbsp; printf("ln(%g/%g) = %g\n", a, b, ln_(div_(a,b)));</tt>
<br><tt>&nbsp; }</tt>
<br><tt>&nbsp; <b>catch</b>(zero_divide) {</tt>
<br><tt>&nbsp;&nbsp;&nbsp; printf("zero division\n");</tt>
<br><tt>&nbsp; }</tt>
<br><tt>&nbsp; <b>catch</b>(domain_error) {</tt>
<br><tt>&nbsp;&nbsp;&nbsp; printf("domain error\n");</tt>
<br><tt>&nbsp; }</tt>
<br><tt>&nbsp; <b>catch_any</b> {</tt>
<br><tt>&nbsp;&nbsp;&nbsp; printf("unknow exception %d\n", <b>exception</b>);</tt>
<br><tt>&nbsp; }</tt>
<br><tt>&nbsp; <b>endtry</b>;</tt>
<p><tt>&nbsp; return EXIT_SUCCESS;</tt>
<br><tt>}</tt></blockquote>
If <tt>div_()</tt> or <tt>ln_()</tt> throw an exception, it will automatically
be caught in the&nbsp; <tt>main()</tt> function and there is no needs to
test the external <tt>errno</tt> variable. The advantages is that <tt>div_()</tt>
or <tt>ln_()</tt> could have been called by a lot of intermediate functions
without any change needed in the exception handling. Note that if <tt>main()</tt>
would have been an intermediate level function, the line <tt>printf("unknow
exception\n");</tt> would have been advantageously replaced by <tt>throw(exception);</tt>
in order to propagate any unprocessed exception. If a <tt>try</tt>, <tt>catch()</tt>
and <tt>catch_any</tt> blocks do not contain variable declaration, the
braces are optional (like for the cases in the <tt>switch()</tt> control
statement).
<p>Throwing an exception while no <tt>try{}</tt> appears at a higher level
is equivalent to call <tt>exit(<i>exception</i>)</tt>.&nbsp; If an exception
is not caught within a <tt>try{} ... endtry</tt> statement, the process
continues just after the <tt>endtry</tt> (C++: exception behavior).
<p>The following OOPC exceptions are already declared in <tt><a href="ooexception.h">ooexception.h</a></tt>:
<ul>
<li>
<tt>ooc_bad_alloc</tt>: memory allocation failure (thrown by <tt>alloc()</tt>).</li>

<li>
<tt>ooc_bad_cast</tt>: bad dynamic cast (not used).</li>

<li>
<tt>ooc_bad_typeid</tt>: bad typeid (not used).</li>

<li>
<tt>ooc_bad_exception</tt>: bad exception (not used).</li>
</ul>
Note: Exceptions are always integers but if you defined <tt>-DALLOW_PTREXCEPTION</tt>,
then OOPC ensures that throwing and catching pointers (object instances,
classes or objects typeid) as exceptions is safe (like in C++).
<p>Throwing an exception can bring dangerous side effects for dynamically
allocated memory between the <tt>try</tt> and the <tt>throw</tt> statements.
To protect memory allocation against exceptions, you may protect them (C++:
<tt>auto_ptr</tt>)
in your intermediate functions:
<blockquote><tt>t_employee *const emp = employee.new("Brown", "Cars");</tt>
<br><tt><b>protectPtr</b>(emp, ooc_delete);</tt>
<br><tt>...</tt>
<br><tt>/* an exception can be thrown here, emp will be safely deleted
*/</tt>
<br><tt>...</tt>
<br><tt><b>unprotectPtr</b>(emp);</tt>
<br><tt><b>delete</b>(emp);</tt></blockquote>
Protection must take place <b><u>just after</u></b> pointer declaration
and assignation. It needs to be in the declaration part of the block since
it also does declarations of hidden variables to manage the stack of protected
pointers.
<p>Unprotection must take place <b><u>before</u></b> the end of the scope
of the protected pointer, but it can be after the freeing of the memory
the pointer was pointing to.
<p>Exception handling and pointer protection do not make any dynamic allocation/freeing,
so throwing a <tt>bad_alloc</tt> exception is safe.
<p><b>Warnings:</b> protection and unprotection must be done in
<b><u>reverse
order</u></b> (think about something like <tt>push(ptr)</tt> and <tt>pop(ptr)</tt>).
Unprotecting a pointer <b>does not free</b> the memory it points to. Unprotecting
a pointer which is not on the top of the stack is safe, therefore unprotecting
the same pointer twice is safe. Throwing an exception in the <i><tt>pointer_free</tt></i>
function gives an <b><u>undefined behavior</u></b> (like in C++). The function
<tt>ooc_delete</tt>
doesn't throw any exception.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Debugging"></a><b><font face="Arial,Helvetica"><font size=+2>Debugging</font></font></b></td>
</tr>
</table>

<p>OOPC provides four kinds of debbuging facilities: tracing function calls
may help in debugging polymorphic methods, tracing exception thrown may
help in debugging uncaught exception, tracing memory allocation may help
in debugging object management and finally tracing object construction
may help in understanding OOPC or find bugs in object hierachy. The file
<tt><a href="ooc.h">ooc.h</a></tt>
includes automatically the header <tt><a href="oodebug.h">oodebug.h</a></tt>
if one of these debugging facilities is activated, but you still need to
add the file <tt><a href="oodebug.c">oodebug.c</a></tt> to your project.
<p><b>Function call</b>
<p>To debug function call, add <tt>DEBUG_VOID_PROTO</tt> or <tt>DEBUG_PROTO</tt>
at the beginning of the arguments list of functions prototypes and declaration
and add <tt>DEBUG_VOID_ARGS</tt> or <tt>DEBUG_ARGS</tt> at the beginning
of the arguments list of functions calls. The <tt>VOID</tt> versions are
for functions which normally have no arguments. To trace functions which
have <tt>XXX_PROTO</tt> and <tt>XXX_ARGS</tt> definition and calls, add
<tt>DEBUG_DISPCALL(<i>file</i>,
<i>string</i>)</tt>
in their core where
<i><tt>file</tt></i> can <tt>stderr</tt> and <i><tt>string</tt></i>
any message.
<p>Then compiling your project with the flag <tt>-DDEBUG_CALL</tt> will
activate the <i>function call</i> debugging and will give an output like:
<blockquote><tt><i>file</i>(<i>line</i>):<i>calling_function</i> - <i>called_function</i>:<i>message</i></tt></blockquote>
for each call of a traced function. This is helpful to trace messages.
<p><b>Exception throw</b>
<p>Compiling your project with the flag <tt>-DDEBUG_THROW</tt> will activate
the <i>exception throw</i> debugging and will give an output like:
<blockquote><tt><i>file</i>(<i>line</i>):<i>throwing_function:</i> exception
'<i>exception</i>' (id #) thrown</tt></blockquote>
for all thrown exception. This is helpful to trace uncaught exceptions.
<p><b>Memory allocation</b>
<p>Put <tt>DEBUG_DISPMEM(<i>file</i>)</tt> where <i><tt>file</tt></i> may
be <tt>stderr</tt> in your program, usually before exit points and compile
your project with the flag <tt>-DDEBUG_MEM</tt> to activate the memory
allocation debugging. If you have any memory leaks, you will have an output
which will look likes:
<blockquote><tt>Index&nbsp; Address&nbsp;&nbsp;&nbsp; Size&nbsp;&nbsp;&nbsp;&nbsp;
Begin End&nbsp;&nbsp; File(Line) - Total size 10</tt>
<br><tt>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x804a828&nbsp; 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
....&nbsp; ....&nbsp; test_protection.c(41):div2_</tt></blockquote>
This is a memory status report where you find the pointer index, the pointer
value, the memory size allocated, the beginning of the memory bloc (4 characters),
the end of the memory bloc (4 characters) and the location <tt>file:line:function</tt>
where the pointer has been allocated. If you try to free a corrupted memory
bloc, you will have an output which will look likes:
<blockquote><tt>Heap corrupted @ beginning of 0x804a848&nbsp; - test_protection.c(48):div2_</tt>
<br><tt>Heap corrupted @&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; end of 0x804a848&nbsp;
- test_protection.c(48):div2_</tt>
<br><tt>Index&nbsp; Address&nbsp;&nbsp;&nbsp; Size&nbsp;&nbsp;&nbsp;&nbsp;
Begin End&nbsp;&nbsp; File(Line) - Total size 10</tt>
<br><tt>0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x804a848&nbsp; 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
....&nbsp; ....&nbsp; test_protection.c(41):div2_ **INVALID**</tt></blockquote>
The first two lines report that a memory corruption has been detected at
the beginning and at the end of the memory bloc. The last two lines are
the memory status report were the pointer 0 is now tagged as <tt>INVALID</tt>.
<p>You can also check for a memory bloc validity with <tt>memchk(<i>pointer</i>,
<i>file</i>)</tt>.
If bloc is valid, nothing is displayed otherwise you get corruption error
messages and the returned value -1.
<p>Note 1: Debugging protected pointers (see <a href="#Exceptions">Exceptions</a>)
may cause some problems since the exception handler does not provide debugging
information to the free function. Therefore, you might use a wrapper to
the free function as shown in the <tt><a href="examples/test_protection.c">test_protection.c</a></tt>
file.
<p>Note 2: Since <tt>oodebug.h</tt> wraps dynamic allocation functions
like <tt>malloc()</tt> and <tt>strdup()</tt> with macros, it must always
be included after the standard headers <tt>stdlib.h</tt> and <tt>string.h</tt>.
The same remark applies to <tt>ooc.h</tt> since it automatically includes
<tt>oodebug.h</tt>
if you specify <tt>-DDEBUG_MEM</tt>.
<p><b>Object construction</b>
<p>To see the construction of an object or a class in memory, compile your
project with the flag
<tt>-DDEBUG_OBJ</tt> to enable debugging of objects
and classes construction. Then using&nbsp; <tt>ooc_printObjInfo(<i>file</i>,
<i>object</i>)</tt>
and <tt>ooc_printClassInfo(<i>file</i>, <i>object</i>)</tt> you can display
the components of an object or a class. In <tt><a href="examples/test_manager.c">test_manager.c</a></tt>,
<tt>ooc_printObjInfo(stdout,
mng)</tt> will print out something like:
<blockquote><tt>OBJECT manager @ 0x804b258</tt>
<br><tt>&nbsp; ctor&nbsp; @ 0x804afc0</tt>
<br><tt>&nbsp; info&nbsp; @ 0x804afe0</tt>
<br><tt>&nbsp; vtbl&nbsp; @ 0x804b004</tt>
<br><tt>&nbsp; class @ 0x804b01c</tt>
<br><tt>&nbsp; SUPEROBJECT employee @ 0x804b258</tt>
<br><tt>&nbsp;&nbsp;&nbsp; base @ 0x804b258 (offset = +0)</tt>
<br><tt>&nbsp;&nbsp;&nbsp; info @ 0x804aee0</tt>
<br><tt>&nbsp;&nbsp;&nbsp; SUPEROBJECT person @ 0x804b258</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; base @ 0x804b258 (offset = +0)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; info @ 0x804ae60</tt>
<br><tt>&nbsp; SUPEROBJECT education @ 0x804b264</tt>
<br><tt>&nbsp;&nbsp;&nbsp; base @ 0x804b258 (offset = +12)</tt>
<br><tt>&nbsp;&nbsp;&nbsp; info @ 0x804af60</tt></blockquote>
while <tt>ooc_printClassInfo(stdout, mng)</tt> will print out something
like:
<blockquote><tt>CLASS manager @ 0x804b01c</tt>
<br><tt>&nbsp; ctor&nbsp; @ 0x804afc0</tt>
<br><tt>&nbsp; info&nbsp; @ 0x804afe0</tt>
<br><tt>&nbsp; vtbl&nbsp; @ 0x804b004</tt>
<br><tt>&nbsp; SUPERCLASS employee @ 0x804af10</tt>
<br><tt>&nbsp;&nbsp;&nbsp; ctor&nbsp; @ 0x804aec0</tt>
<br><tt>&nbsp;&nbsp;&nbsp; info&nbsp; @ 0x804aee0</tt>
<br><tt>&nbsp;&nbsp;&nbsp; vtbl&nbsp; @ 0x804af04</tt>
<br><tt>&nbsp;&nbsp;&nbsp; SUPERCLASS person @ 0x804ae90</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ctor&nbsp; @ 0x804ae40</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; info&nbsp; @ 0x804ae60</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; vtbl&nbsp; @ 0x804ae84</tt>
<br><tt>&nbsp; SUPERCLASS education @ 0x804af90</tt>
<br><tt>&nbsp;&nbsp;&nbsp; ctor&nbsp; @ 0x804af40</tt>
<br><tt>&nbsp;&nbsp;&nbsp; info&nbsp; @ 0x804af60</tt>
<br><tt>&nbsp;&nbsp;&nbsp; vtbl&nbsp; @ 0x804af84</tt></blockquote>

<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="ISO_C99"></a><b><font face="Arial,Helvetica"><font size=+2>ISO
C99</font></font></b></td>
</tr>
</table>

<p>ISO C99 provides new interesting features like the <tt>__VA_ARGS__</tt>
predefined macro which simplify the use of macros with variable number
of arguments. Using <tt>__VA_ARGS__</tt> allows to replace <tt>sendMsg_(<i>obj</i>,
<i>msg</i>)
<i>args</i>
__;</tt> by <tt>sendMsg_(<i>obj</i>, <i>msg</i>, (<i>args</i>));</tt> which
may be considered to be closer to the C grammar. I still prefer to group
<tt>args</tt>
into parenthesis to be homogeneous with the <tt>sendMsg(<i>obj</i>,
<i>msg</i>);</tt>
command. This change can be applied to all the OOPC commands ending by
an underscore (see <tt><a href="ooc99.h">ooc99.h</a></tt>).
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Performances"></a><b><font face="Arial,Helvetica"><font size=+2>Performances</font></font></b></td>
</tr>
</table>

<p>Methods calling and&nbsp; messages sending <i>speed efficiency</i> is
more or less the same as in C++ since the programming techniques used behind
are very close. So in general, you will nearly get the same performance
as in C++ <i>without inlining</i> (+/- 10%). Object instance size is exactly
the same as its C++ equivalent without drastic size optimisation.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Keywords"></a><b><font face="Arial,Helvetica"><font size=+2>Keywords</font></font></b></td>
</tr>
</table>

<p>The list of introduced keywords at the preprocessor level is given in
the following table:
<br>&nbsp;
<table BORDER COLS=4 WIDTH="100%" NOSAVE >
<tr ALIGN=LEFT VALIGN=TOP NOSAVE>
<td WIDTH="25%" NOSAVE>
<center><b>INTERFACE</b></center>

<p><b>Interface</b>
<br><tt>OBJECT</tt>
<br><tt>t_OBJECT</tt>
<br><tt>BASEOBJECT_INTERFACE</tt>
<br><tt>BASEOBJECT_METHODS</tt>
<br><tt>OBJECT_INTERFACE</tt>
<br><tt>OBJECT_METHODS</tt>
<br><tt>ABSTRACTCLASS_INTERFACE</tt>
<br><tt>CLASS_INTERFACE</tt>
<br><tt>ENDOF_INTERFACE</tt>
<br><tt>INHERIT_MEMBERS_OF()</tt>
<br><tt>INHERIT_METHODS_OF()</tt>
<p><b>Encapsulation</b>
<br><tt>public()</tt>
<br><tt>private()</tt>
<p><b>Declaration</b>
<br><tt>classMethod()</tt>
<br><tt>classMethod_()</tt>
<br><tt>method()</tt>
<br><tt>method_()</tt>
<br><tt>constMethod()</tt>
<br><tt>constMethod_()</tt>
<p><b>Messages</b>
<br><tt>sendMsg()</tt>
<br><tt>sendMsg_()</tt>
<br><tt>sendCMsg()</tt>
<br><tt>sendCMsg_()</tt>
<p><b>Miscellaneous</b>
<br><tt>super()</tt>
<br><tt>className()</tt>
<br><tt>objCopy()</tt>
<br><tt>isA()</tt>
<br><tt>offsetOf()</tt>
<br><tt>typeid()</tt>
<br><tt>base_cast()</tt>
<br><tt>super_cast()</tt>
<br><tt>static_cast()</tt>
<br><tt>dynamic_cast()</tt>
<br><tt>delete()</tt>&nbsp; (macro)</td>

<td WIDTH="25%" NOSAVE>
<center><b>IMPLEMENTATION</b></center>

<p><b>Implementation</b>
<br><tt>BASEOBJECT_IMPLEMENTATION</tt>
<br><tt>OBJECT_IMPLEMENTATION</tt>
<br><tt>ABSTRACTCLASS_IMPLEMENTATION</tt>
<br><tt>CLASS_IMPLEMENTATION</tt>
<br><tt>ENDOF_IMPLEMENTATION</tt>
<br><tt>SUPERCLASS()</tt>
<p><b>Initialisation</b>
<br><tt>methodName()</tt>
<br><tt>methodOvldName()</tt>
<p><b>Declaration</b>
<br><tt>initClassDecl()</tt>
<br><tt>dtorDecl()</tt>
<br><tt>classMethodDecl()</tt>
<br><tt>classMethodDecl_()</tt>
<br><tt>methodDecl()</tt>
<br><tt>methodDecl_()</tt>
<br><tt>methodOvldDecl()</tt>
<br><tt>methodOvldDecl_()</tt>
<br><tt>constMethodDecl()</tt>
<br><tt>constMethodDecl_()</tt>
<br><tt>constMethodOvldDecl()</tt>
<br><tt>constMethodOvldDecl_()</tt>
<p><b>Miscellaneous</b>
<br><tt>initSuper()</tt>
<br><tt>objDefault()</tt>
<br><tt>overload()</tt>
<br><tt>sub_cast()</tt>
<p><b>+ INTERFACE keywords</b>
<br>&nbsp;</td>

<td WIDTH="25%" NOSAVE>
<center><b>CLASS</b></center>

<p><b>Generated class members</b>
<br><tt><i>object</i>()&nbsp; </tt>(constructor)
<br><tt>alloc()&nbsp;&nbsp; </tt>(allocator)
<p><b>Required class members</b>
<br><tt>_<i>object</i>() </tt>(destructor)
<p><b>Global names</b>
<br><tt><i>object</i>&nbsp;&nbsp; </tt>(class)
<br><tt>t_<i>object</i> </tt>(object)
<br><tt>t_object </tt>(generic object)
<p><b>Global functions</b>
<br><tt>ooc_delete()</tt> (function)</td>

<td WIDTH="25%" NOSAVE>
<center><b>EXCEPTION</b></center>

<p><tt>try {}</tt>
<br><tt>catch() {}</tt>
<br><tt>catch_any {}</tt>
<br><tt>endtry</tt>
<br><tt>throw()</tt>
<br><tt>exception</tt>
<br><tt>protectPtr()</tt>
<br><tt>unprotectPtr()</tt>
<br>&nbsp;
<br>&nbsp;
<br>
<br>
<center>
<p><b>GENERICITY</b></center>

<p><tt>t_OBJECT&nbsp;&nbsp; </tt>(generic object type)
<br><tt>GENERIC()</tt>
<br><tt>GENERIC_DTOR()</tt>
<p><b>Required defines</b>
<br><tt>gTypePrefix</tt>
<br><tt>gType1</tt>
<br>&nbsp;</td>
</tr>
</table>

<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Examples"></a><b><font face="Arial,Helvetica"><font size=+2>Examples</font></font></b></td>
</tr>
</table>

<p><b>ISO C89</b>
<ul>
<li>
<tt>ooc.[hc]</tt> (OOPC files in C89).</li>

<li>
<tt>exception.[hc], ooexception.h</tt> (Exception files).</li>

<li>
<tt>oodebug.[hc]</tt> (Debugging files).</li>

<li>
<tt>example.[hc]</tt> <tt>test_example.c</tt> (OOPC hierachy examples).</li>

<li>
<tt>person.[hc] employee.[hc] education.[hc] manager.[hc] test_manager.c</tt>
(OOPC basic examples).</li>

<li>
<tt>g_memBlock.[hc] g_array.[hc] memBlock.[hc] array.[hc] test_array.c</tt>
(OOPC advanced examples).</li>

<li>
<tt>test_exception.c test_protection.c</tt> (exceptions tests examples).</li>

<li>
<tt>compile.sh compile_tests.sh</tt> (examples of gcc commands).</li>
</ul>
<b>ISO C99</b>
<ul>
<li>
<tt>ooc99.h</tt> (OOPC file in C99). Rename it to <tt>ooc.h</tt> to work
with others OOPC files (Not examples).</li>
</ul>
<b>C++</b>
<ul>
<li>
<tt>example.[HC]</tt> <tt>test_example.C</tt> (C++ hierachy examples).</li>

<li>
<tt>person.[HC] employee.[HC] education.[HC] manager.[HC] test_manager.C</tt>
(C++ basic examples).</li>

<li>
<tt>compile-cpp.sh </tt>(example of g++ commands).</li>
</ul>
All these example files are included into <tt><a href="oopc.tgz">oopc.tgz</a></tt>
or <tt><a href="oopc.zip">oopc.zip</a></tt>.
<br>&nbsp;
<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="References"></a><b><font face="Arial,Helvetica"><font size=+2>References</font></font></b></td>
</tr>
</table>

<p>Links given below can be read for information but they are not required
to understand this paper since they do not follow the same philosophy.
In fact, I disagree with most of the techniques presented into these references:
<ul>
<li>
Abusive use of global name to simplify object methods call.</li>

<li>
Abusive use of untyped pointers to handle polymorphism.</li>

<li>
Abusive use of unprotyped functions to handle polymorphism.</li>

<li>
Abusive use of structure field mapping to handle polymorphism and inheritance.</li>

<li>
Abusive use of macros for classes definitions and inheritances (two macros
per class).</li>

<li>
Object messages managed by a <tt>switch</tt> statement.</li>

<li>
Multiple inheritance not supported.</li>

<li>
Specific preprocessor required to manage (too complex) techniques.</li>

<li>
Some techniques are not portable (problem of data alignment) and/or slow.</li>

<li>
Difficult to implement genericity on top of these techniques.</li>
</ul>
<b>List of OOPC references</b>
<blockquote>[1] La programmation par objets en langage C, by A. Gourdin,
Technique et Documentation 1991
<br>[2] <a href="http://a-sync.com/contents.htm">Reusable Software Components</a>,
by Truman T. Van Sickle, Prentice-Hall 1996
<br>[3] <a href="http://www.accu.org/acornsig/public/articles/oop_c.html">Object-oriented
programming in C</a>, by Paul Field, November 1991
<br>[4] <a href="http://sunsite.nstu.nsk.su/sunworldonline/swol-10-1995/swol-10-ooc.html">Object-oriented
programming using C</a>, by Dave St. Clair, October 1995
<br>[5] <a href="http://web2.airmail.net/plong/oopc.html">Object Technology
with C</a>, by Paul Long, September 1995
<br>[6] <a href="http://www.planetpdf.com/binthing~WebPageID,620.htm">Object
Orientated Programming in ANSI-C</a>, by Axel Schreine, October 1993
<p><b>Some references of the C/C++ Users Journal</b>
<p>[7] Object-Oriented Programming As A Programming Style, by E. White,
February 1990
<br>[8] Object-Oriented Programming in C, by D. Brumbaugh, July 1990
<br>[9] Using OOPs in Mac Design, by R. Rathe, August 1990
<br>[10] Creating C++-Like "Objects" in C, by C. Skelly, December 1991
<br>[11] OOP Without C++, by B. Bingham, T. Schlintz and G. Goslen, March
1992
<br>[12] Using OOP Techniques Instead of switch in C++, by M. Wiebel and
S. Halladay, October 1992
<br>[13] Extending C for Object-Oriented Programming, by G. Colvin, July
1993</blockquote>
<b>List of C++ references</b>
<blockquote>[1] <font color="#FF0000">The C++ Programming Language</font>,
3rd edition, by Bjarne Stroustrup, Addison Wesley 1997
<br>[2] <a href="http://www.cygnus.com/misc/wp/">The ANSI C++ Specifications</a>
(Draft), December 1996
<br>[3] Annotated C++ Reference Manual, by M. A. Ellis and B. Stroustrup,
Addison Wesley 1990
<br>[4] Effective C++, 2nd edition, by Scott Meyers, Addison Wesley 1997
<br>[5] More Effective C++, by Scott Meyers, Addison Wesley 1997
<br>[6] <font color="#FF0000">Inside the C++ Object Model</font>, by Stanley
B. Lippman,&nbsp; Addison Wesley 1996
<br>[7] Essential C++, by Stanley B. Lippman, Addison Wesley 2000
<br>[8] Exceptional C++, by Herb Sulter, Addison Wesley 2000 (see also
<a href="http://www.gotw.ca">Guru
of the Week</a>)
<br>[9] Modern C++ Design, by Andrei Alexandrescu, Addison Wesley 2001
(see also <a href="http://www.awl.com/cseng/titles/0-201-70431-5/loki.zip">Loki</a>)
<br>[10] Advanced C++, by James Coplien, Addison Wesley 1992
<br>[11] Secrets of C++ Master, by Jeff Alger, AP Professional 1995
<br>[12] C++ Primer, 3rd edition, by Stanley B. Lippman,&nbsp; Addison
Wesley 1998
<br>[13] Scientific and Engineering C++, by John J. Barton and Lee R. Nackman,
Addison Wesley 1994
<br>[14] <a href="http://www.elj.com/cppcv3/">C++??: A Critique of C++</a>,
by Ian Joyner, October 1996</blockquote>

<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="Mailing_List"></a><b><font face="Arial,Helvetica"><font size=+2>Mailing
List</font></font></b></td>
</tr>
</table>

<p>If you are interested by updates and discussions about Object Oriented
Programming in C, you can subscribe to the public mailing list <a href="mailto:forum-oopc@listbox.cern.ch">forum-oopc</a>
by sending an e-mail to the <a href="mailto:ListServer@listbox.cern.ch">CERN
Listbox Server</a> with the following content (subject is ignored):
<blockquote><tt>subscribe <i>listname</i> <i>your-email-address</i></tt></blockquote>

<table CELLPADDING=5 COLS=1 WIDTH="100%" BGCOLOR="#66FFFF" NOSAVE >
<tr NOSAVE>
<td NOSAVE><a NAME="ChangeLog"></a><b><font face="Arial,Helvetica"><font size=+2>ChangeLog</font></font></b></td>
</tr>
</table>

<ul>
<li>
01/06/2001 C/C++ Journal references added and some more C++ books.</li>

<li>
17/05/2001 Bug corrected in <tt>methodOvldName</tt> (thanks to Jeff Ervin).
The arguments order has been permuted in all xxxOvldxxx macros.</li>

<li>
16/05/2001 <tt>ALLOW_PTREXCEPTION</tt> and <tt>DEBUG_THROW</tt> flags added
to allow pointers to be thrown (instead of just integers) and to trace
thrown exceptions.</li>

<li>
08/05/2001 <tt>_OBJECT</tt> removed (may conflict with ISO implementation),
<tt>dtorDecl()</tt>
added. <tt>_GENERIC()</tt> replaced by <tt>GENERIC_DTOR()</tt>.</li>

<li>
06/05/2001 <tt>strdup</tt> and <tt>ALLOW_STRDUP</tt> added.</li>

<li>
05/05/2001 Debug files <tt>oodebug.[hc]</tt> added.</li>

<li>
02/05/2001 OOPC paper and examples are completely reformulated.</li>

<li>
30/04/2001 Object model changed to C++ Object Model. Files <tt>object.[hc]</tt>
are renamed to <tt>ooc.[hc]</tt>.</li>

<li>
05/04/2001 RTTI and <tt>dynamic_cast()</tt> added.</li>

<li>
22/03/2001 <tt>initClass()</tt> is automatically called once (update of
<tt>object.h</tt>).
Mailing list added.</li>

<li>
19/03/2001 ChangeLog added. Reference [6] added. <tt>constMethod</tt> and
const types added. Dynamic polymorphism commented. <tt>className()</tt>
on abstract superclasses commented. Almost all files updated.</li>

<li>
16/03/2001 Update of <tt>exception.h</tt> (a backslash was missing in a
macro). Multiple inheritance explanations added.</li>

<li>
15/03/2001 Change of <tt>send()</tt> and <tt>send_()</tt> to <tt>sendMsg()</tt>
and
<tt>sendMsg_()</tt> to avoid conflict with POSIX <tt>send()</tt> (sockets
messages).</li>
</ul>

</body>
</html>
